Web-based network monitoring tool

ABSTRACT

A monitoring tool for use with one or more automatic call distributors (ACD) which automatically and continuously polls or queries the ACDs to monitor not only alarm conditions but other conditions, such as agent staffing levels, call answering time, call routing and traffic conditions. Such continuous and automatic monitoring and querying of the ACD in accordance with the present invention is thus able to improve the overall efficiency of such ACDs by improving the service response time of such ACDs. In accordance with one aspect of the invention, the status records of the ACDs maybe directed to a website, for example, on an enterprise Intranet website to enable any of the company representatives with access rights to access the performance of the ACD network from any location. Other data, such as the trunk inventory record keeping system (TIRKS) may also be displayed on the website to facilitate troubleshooting of alarm conditions. Another aspect of the invention is the ability to provide automatic paging for predetermined alarm status condition.

BACKGROUND OF THE INVENTION

1. Field of the Invention:

The present invention relates to a monitoring tool for use in atelecommunications system which automatically monitors one or moreautomatic call distributors (ACD) and provides an indication of thestatus of such ACDs in essentially real time.

2. Description of the Prior Art:

Automatic call distributors (ACD) are known in the art. Such ACDs aretelecommunications devices, used by various manufactures and serviceproviders, to handle a relatively huge volume of calls and distributethem among a relatively few agents. Such ACDs are known to be networkedand interconnected with interactive voice response units (IVR). As such,calls to a company's customer service telephone are provided with menuoptions by the IVR depending on the type of service required. Thecaller's selection is then used to route the call to the appropriate ACDin the network. One or more agent groups are normally affiliated witheach of the ACDs in the network. The call is routed to an agent groupand held until one of the agents is available to take the call. Thecalls are normally distributed to the agents according to variouscriteria. For example, the call may be routed to the agent in the agentgroup that has been idle the longest. Alternatively, the call may berouted to the agent based on the caller's telephone number or the numberdialed by the caller. If all of the agents are busy, the call may beheld in queue or routed to another agent group, for example, for apredetermined time period or the caller may be requested to leave avoice mail message for later call back.

Such ACDs are known to be provided by a number of manufacturers. Forexample, Lucent Technologies, Rockwell, Toshiba and STE are all knownmanufacturers of ACDs. An important aspect of such ACDs is theefficiency by which the incoming service calls are handled. As such, allof the providers of such ACDs are known to provide online monitoring ofthe ACDs. Unfortunately, such systems are monitored manually on a querybasis. In other words, service technicians must manually query or polleach of the ACDs to determine its status, which can be time consuming.Once an alarm condition is detected, a service technician issubsequently dispatched to correct the problem. Unfortunately, with sucha system, an ACD can be out of service for several hours and perhapsdays depending on the location of the service technician relative to theACD and the severity of the problem. While such ACDs are out of service,the call answering time potentially increases, perhaps leading manycustomer calls unanswered, potentially causing customer ill will towardthe company and increased call traffic when the ACD is returned toservice. Thus, there is a need for a monitoring system which lowers theresponse time and provides continuous and automatic monitoring of thevarious conditions in order to reduce the amount of time such ACDs areout of service.

BRIEF DESCRIPTION OF THE DRAWINGS

Various objects and advantages of the present invention will be realizedupon consideration of the following specification and attached drawingwherein:

FIG. 1 is a block diagram of an inbound and outbound distribution systemfor a network of automatic call distributors (ACD) in accordance withthe present invention.

FIG. 2 is an exemplary block diagram of a network of ACDs with exemplaryagent groups associated with each of the ACDs according to the presentinvention.

FIG. 3 is a detailed block diagram of a single ACD in accordance withthe present invention.

FIG. 4 is an exemplary home web page for an ACD in accordance with thepresent invention which provides hyperlinks to various web pages for allincoming and outgoing trunk groups connected to the ACD as well asauxiliary equipment associated with the ACD.

FIGS. 5A, 5B represents an exemplary web page, linked to the web pageillustrated in FIG. 4, illustrating the status of incoming trunk groupscoupled to the ACD illustrated in FIG. 4.

FIGS. 6A, 6B represents an exemplary web page, linked to the web pageillustrated in FIGS. 5A, 5B, illustrating the trunk inventory recordkeeping system (TIRKS) for a selected trunk group illustrated in FIGS.5A and 5B.

FIGS. 7A, 7B represents an exemplary web page, linked to the exemplaryhome web page illustrated in FIG. 4 illustrating the status of thevarious expansion port network (EPN) connected to the ACD illustrated inFIG. 4.

FIG. 8 represents an exemplary web page linked to the home web pageillustrated in FIG. 4, illustrating an alarm log for the ACD illustratedin FIG. 4.

FIG. 9 is an exemplary web page, linked to the ACD home web pageillustrated in FIG. 4 illustrating the ACD agent status.

FIG. 10 is an exemplary web page, linked to the EPN web page illustratedin FIGS. 7A, & B which illustrates the EPN cabinet stations and portassignments.

FIG. 11 is an exemplary web page, linked to the home web pageillustrated in FIG. 4, which illustrates the traffic Or load of allcustomer care centers (CCC) and inbound traffic to the ACD in FIG. 4.

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to a monitoring tool for use with one ormore automatic call distributors (ACD) which automatically andcontinuously polls or queries the ACDs to monitor not only alarmconditions but other conditions, such as agent staffing levels, callanswering time, call routing and traffic conditions. Such continuous andautomatic querying of the ACD in accordance with the present inventionis thus able to improve the overall efficiency of such ACDs by improvingthe service response time of such ACDs. In accordance with one aspect ofthe invention, the status of the ACDs may be directed to a website, forexample, on an enterprise Intranet website to enable any of the companyrepresentatives with access rights to access the real time performanceof the ACD network from any location. Another aspect of the invention isthe ability to provide automatic paging for predetermined alarm statuscondition.

Although the present invention is illustrated and described relative toLucent Definity G3R ACDs, the principles of the present invention areapplicable to virtually any ACD or other telecommunications equipmentwhich stores status data.

An exemplary block diagram illustrating the inbound and outbound trunksfor an exemplary network of ACDs is illustrated in FIG. 1. As shown, theexemplary network, generally identified with the reference numeral 20,is shown with, for example, six (6) exemplary ACDs 22, 24, 26, 28, 30and 32. As shown, the exemplary ACD network 20 may contain ACDs indifferent states in different regions in the country. For example, asshown in FIG. 1, three ACDs 22, 24 and 26 may be located in Illinois,designated as Illinois-1; Illinois-2 and Illinois-3, while two ACDs 28and 30 are located in Michigan and designated as Michigan-1 andMichigan-2. The sixth ACD may be located in Ohio and designated Ohio.

Each ACD 22, 24, 26, 28, 30 and 32 may include two inbound trunk groupsand two outbound trunk groups. For example, the ACD 22 may include twoinbound trunk groups 34 and 36 from independent long distance carrierswitches 38 and 40. In order to improve the inbound reliability of thesystem, calls placed to a central office 42 may be routed to twodifferent access tandems 44 and 46 by way of a plurality of trunks 48and 50. The access tandems 44 and 46 may also be tied together by way ofintermachine trunks (IMT) 52. Separate trunk groups 54, 56, 58 and 59from each of the access tandems 44 and 46 are applied to each of thelong distance carrier switches 38 and 40. In particular, each accesstandem is connected to both of the long distance carrier switches 38 and40 by way of a plurality of trunk groups 54 and 56. Similarly, theaccess tandem 46 may be connected to the long distance carrier switches38 and 40 by way of a plurality of trunk groups 56 and 58. With such aconfiguration, should one of the access tandems 44 or 48 fail, calls canbe routed through the other access tandem since both access tandems feedeach of the long distance carrier switches 38 and 40; and the accesstandems 44 and 46 are tied together by way of the IMT 52. The exemplaryin bound distribution system may also be configured to minimize serviceloss upon failure of one of the long distance carrier switches 38 and40. In particular, as mentioned above, each of the ACDs 22, 24, 26, 28,30 and 32 has two incoming trunk groups 34 and 36; one from each of thelong distance carrier switches 38 and 40 respectively. Thus, should oneof the long distance carrier switches 38, 40 fail, calls can be routedto the appropriate ACD 22, 24, 26, 28, 30 and 32 by the other longdistance carrier switch. Similarly, should problems develop with one ofthe trunk inbound trunk groups 34 or 36, calls to the ACD can bere-routed by way of the other trunk groups to provide improved overallreliability of the system.

Each of the ACDs 22, 24, 26, 28, 30 and 32 may also provided with, forexample, two outgoing trunk groups. For example, the ACD 22 may beprovided with the outgoing trunk groups 58 and 60. These outbound trunkgroups enable outbound calls from the ACDs 22, 24, 26, 28, 30 and 32 tobe directed to central offices (not shown). In order to providereliability of outgoing calls from each of the ACDs 22, 24, 26, 28, 30and 32, each of the outgoing trunk groups 58 and 60 are directed to aseparate central office (not shown).

FIG. 2 illustrates a block diagram of an exemplary ACD network 20. Asmentioned above, the ACD network in accordance with an exemplaryembodiment of the invention includes six ACDs 22, 24, 26, 28, 30 and 32.The exemplary ACD network 20 may be configured to route calls, forexample, to approximately 6,000 agents, distributed in one or moreregions around the country. Each ACD 22, 24, 26, 28, 30 and 32 mayinclude one or more customer care centers (CCC) for handling variouscustomer services, generally identified with the reference numeral 62.Each CCC 62 may include one or more expansion port networks (EPN). EachEPN may be used to route calls to a plurality of agents, for example, 90agents. In addition to the CCCs 62, each ACD 22, 24, 26, 28, 30 and 32may utilize EPNs for special purpose applications, such as training,generally identified with the reference numeral 24, collections,generally identified with the reference numeral 66 and, for example,executive applications, generally identified with the reference numeral68.

As discussed above, each of the ACDs 22, 24, 26, 28, 30 and 32 is fedwith two incoming trunk groups 34 and 36 (FIG. 1) and two outgoing trunkgroups 58 and 60. The outgoing trunk groups may be used for customercall back or transferring calls to different ACDs or CCC. In addition,each of the ACDs 22, 24, 26, 28 and 30 may be connected to the otherfive ACDs by a number of trunk groups. For example, the ACD 22 may beconnected to the ACD 32 by way of an intermachine trunk group (IMT) 68.Similarly, the ACD 22 may be connected to the ACDs 24, 26, 28 and 30 byway of IMT groups 70, 72, 74 and 76. As such, should one of the ACDs ortrunk groups fail, calls can be routed by way of the IMTs to other ACDsin the network.

FIG. 3 is a block diagram of an exemplary block diagram of a consumervoice network, generally identified with the reference numeral 100. Forexample, 800 number calls placed from a telephone 102 are directed to acentral office, for example, the central office 42. The network servicedatabase 104 at the central office 42 determines the responsibleorganization for handling the call. In particular, the 800 number islooked up in the database 104, and an appropriate carrier identificationcode (CIC) is returned. In this example, since the call is directed toan 800 number, the network service database 104 will return a CICdirecting that the calls be directed to an access tandem 44, 46 and along distance carrier switch, for example, the long distance carrierswitches 38 and 40. Each long distance carrier switch 38 and 40 includesa service control point (SCP) data base 104 used to look up the 800number and direct the call to one of the ACDs 22, 24, 26, 28, 30 and 32by way of one of two incoming trunk groups 34 and 36.

Initially the call is routed to an interactive voice response unit 106,for example, an IBM Direct Talk 6000, where the caller may be givenvarious voice menu options in which the customer is directed to respondby way of the touch-tone telephone 102. In addition, the customer may berequired to key in a telephone number. The information input by thecustomer is then looked up on a database, such as an Ameritech CustomerInformation System (ACIS) data base 106 containing customer records. Thecustomer record information may then be provided to a server 108, usedto provide the information back to the ACD 22, 24, 26, 28, 30 and 32 anddisplay the information on the screen of the next available agent. Thecall and the above-mentioned information are then routed to anappropriate CCC 68. In particular, the calls are routed to an EPN 108,which, in turn, routes the calls to the next available agent. Each agentis provided with a work station 112. All the work stations may beconnected together in a network, for example a token ring network. Thecustomer records may then be “screen popped” onto the agents workstations 112, when the agent picks up the call.

Other options may be provided with the ACDs 22, 24, 26, 28, 30 and 32.For example, a predictive dialer 116 may be provided and connected tothe ACD 22, 24, 26, 28, 30 and 32. The predictive dialer, 116 may beused for automatic dialing for various purposes, such as collections. Asshown in FIG. 2, the ACDs 26 and 30 are provided with predictivedialers. In addition, a call management system (CMS) 118 may be providedwith each ACD 22, 24, 26, 28, 30 and 32. The CMS 118 collects data fromthe ACD 22, 24, 26, 28, 30 and 32 and stores the data for 24 hours. Thedata collected by the CMS 118 is available by way of a dial-up modem.

As mentioned above, each ACD 22, 24, 26, 28, 30 and 32 may be used toroute calls to one or more EPNs 108 (FIG. 3). A typical single EPN maybe used to direct calls to, for example, 90 customer service agents.Thus, any time there is an outage related to one of the ACDs 22, 24, 26,28, 30 or 32, several problems can result. Such an outage causes aninterruption of customer service or other function associated with theACD. In addition, such outages idle a relatively significant number ofcustomer service agents. Depending on the severity of the outage andavailability of service technicians, such outages can thus besubstantial. As such, various vendors of ACDs, such as LucentTechnologies, have developed software which allows the status of the ACD22, 24, 26, 28, 30 and 32 to be stored and thus be manually polled byway of a dial-up modem with standard communications software toascertain the status of the ACDs 22, 24, 26, 28, 30 and 32. With suchsoftware, it is necessary to manually poll the ACDs 22, 24, 26, 28, 30and 32 on a periodic basis. For a network of ACDs, for example, asillustrated in FIG. 2, a considerable amount of man power is required toperform the manual polling of the ACDs 22, 24, 26, 28, 30 and 32. Inaddition, such systems are reactive. In other words, once an alarmcondition is detected, a service technician is subsequently dispatchedto correct the problem. Unfortunately with such prior art systems, anACD can be out of service for several hours and perhaps days dependingon the severity of the problem and the location of the servicetechnician relative to the ACD 22, 24, 26, 28, 30 and 32.

In order to solve this problem, the present invention automatically andcontinuously polls or queries each of the ACDs 22, 24, 26, 28, 30 and 32on a periodic basis, for example every two minutes, and provides thestatus of the ACDs. The system may also be used to monitor the loadbalance on each of the ACDs 22, 24, 26, 28, 30 and 32 as well as variousother attributes of the system, for example, the call traffic to each ofthe agents, and the average amount of wait time per call. Thisinformation may then be transferred, for example, over a secure line,for example, to a corporate Intranet, and displayed by way of aconventional web browser. As known in the art, such corporate Intranetnetworks are normally protected by a corporate fire wall, which onlyenables authorized users to access the corporate Intranet. As such,anyone with access rights to the corporate Intranet can access the ACDstatus information over the Internet from virtually anywhere in theworld. By providing automatic and continuous polling of the ACDs, thestatus of ACDs can be detected and adjustments made to correct problemsbefore they happen.

Exemplary web pages in accordance with the present invention, adapted tobe displayed by way of a conventional web browser, such as the InternetExplorer and Netscape, are illustrated in FIGS. 4 -11. Referring to FIG.4, an exemplary ACD home page for the ACD 28 is illustrated andgenerally identified with the reference numeral 130. Home pages for theremaining ACDs 22, 24, 26, 30 and 32 would be similar. The ACD home page130 may be provided with three data boxes; a traffic load data box 132;an alarm status data box 134 and a current system status data box 136.

The traffic load data box 132 is adapted to provide the traffic load ofa particular ACD and in particular the traffic load of all of thevarious trunks connected to the ACD including inbound, outbound andintermachine trunks as well as information on the EPNs and other devicesconnected to the ACD, such as an IVR. The traffic load data box 132 maybe provided with five columns 138, 140, 142, 144 and 146. Column 138relates to the trunk group connected to the particular ACD. Inparticular, as mentioned above, each of the ACDs 22, 24, 26, 28 and 30is fed from inbound trunks from the long distance carrier switches 38and 40 (FIG. 1), identified, for example, as Hudson and Troy,respectively as well as the intermachine trunks (IMT) connected to theACD 28 from each of the other ACDs 22, 24, 26, 28, 30 and 32. Column 138also lists the outbound feeds for each ACD (i.e., OUT DETROIT and OUTSOUTHFIELD) as well as supplemental services, such as a direct inlinedial (DID), an interactive voice response (IVR) unit and the contactquality center (CQC). Column 140 may be used to refer to the number oftrunks associated with each of the trunk groups identified in column138. Column 142 may be used to identify the number of trunks out ofservice, while column 144 may be used to display the percent occupancyrate of the various trunk groups.

In accordance with an important aspect of the invention, traffic loadinformation for all the inbound and outbound trunks to the ACD as wellas to the IVR may be displayed graphically in column 146, for example,in the form of a bar graph. For example, as shown in FIG. 4 for the Troytrunk group, identified in row 150 and column 144, a 59% occupancy rateis indicated. This 59% occupancy rate represents the traffic load forthe incoming trunk lines from the Troy long distance carrier switch 40(FIG. 1).

In one embodiment of the invention, different colors may be used toprovide quick visual indication of the occupancy rate. For example, thecolor green may be used to display occupancy rates up to 80% while adifferent color such as yellow may be used to display occupancy rates,for example, greater than 80%. In this way, the load balance of alltrunk groups connected to each of the ACDs 22, 24, 26, 28, 30 and 32 canbe quickly checked at a glance by just monitoring column 146 and notingthe specific color used for the bar graph.

In addition, to the trunk groups connected to the various ACDs 22, 24,26, 28, 30 and 32, the traffic load data block 130 may also be used toprovide access to associated equipment, such as EPNs and CQC (contactquality center). As will be discussed in more detail below, each of theentries in column 138 of the traffic load data box 130 may behyperlinked to successive web pages which provide more detailedinformation. For example, FIGS. 5A and 5B illustrate an exemplary webpage, activated by way of the hyperlink for the Troy trunk group. Inparticular, if the “Troy” hyperlink in column 138 and row 150 of theload balance data box 130 is clicked on, more detailed informationregarding the trunk groups connected between Troy and the ACD 28 isprovided. For example, FIG. 4, column 140 indicates that Troy has 708trunks. FIG. 5A provides the data for those 708 trunks. For example,with reference to FIG. 5A and 5B, six (6) trunk groups (TROY TGN 623,626, 627, 629, 624, 634) are shown from the long distance carrier switch40 (FIG. 1) at Troy to the ACD 28. Each trunk group contains fiveISDN-PRI lines, which each contain 24 circuits to provide a total of 708trunks between the long distance carrier switch 40 and the ACD 28. Theweb page illustrated in FIG. 5A and 5B may be broken into a number ofdata boxes 150, 152, 154, 156, 158 and 160. Each data box 150-160 may beused to display information regarding a single trunk group, which, asmentioned above, may display five ISDN-PRI lines.

Each of the data boxes 150-160 may be provided with a plurality ofcolumns. The first column 162 may be used to represent the trunk groupnumber (TGN). The second column may be used to represent officeequipment (OE). The third column may be used to provide the circuitidentification numbers and may be hyperlinked to local assignmentinformation for each circuit, for example, as illustrated in FIG. 6A and6B. The alarm status may be provided in column 168 for each of theISDN-PRI lines. The columns 171 and 173 may be used for miscellaneousinformation, such as smart jacks, if applicable.

An important aspect of one embodiment of the invention relates to theintegration of other data, which may be other dynamic data not retrievedfrom the ACD, or static data, such as the local circuit assignments andrecords. In particular, the trunk inventory record keeping system(TIRKS) data as illustrated in FIGS. 6A and 6B may be hyperlinked to thetrunk group data illustrated in FIGS. 5A and 5B. Thus, when alarmconditions are detected, the TIRKS data is readily available, forexample, on an enterprise intranet website. As such, trouble shooting ofalarm conditions is greatly reduced.

Returning to the ACD home page illustrated in FIG. 4, an “ALARM STATUS”data box 134 may also be provided. As currently shown, the alarm statusbox 134 indicates that there are no alarms (i.e. “There are no alarms”).The alarm status box 134 may be used to represent alarms which may beflashing and/or displaying different colors. For example, minor alarmsmay be displayed in yellow while major alarms are displayed in red. Thealarm status data box 134 may be hyperlinked to a historical alarm log,for example as illustrated in FIG. 8, which maintains the status ofalarms for a predetermined period of time, such as 30 days.

As mentioned above, the ACD home page 130 may also be provided with a“current system status” data box 136 which gives different types ofuseful information regarding the call traffic on the system, as well asother useful information regarding the system. For example, the currentsystem status data box 136, as shown, indicates that there are 233agents active and that there are 68 calls in the queue and the longestcall has been in the queue for 10 minutes, 12 seconds. The currentsystem status box 136 may contain a hyperlink to an agent status webpage, for example, as generally shown in FIG. 9. The agent status webpage may be used to provide different information regarding the agentstatus. For example, the agent status web page may provide informationregarding the skill level of the agent, for example as provided incolumn 170, the number of agents active, as indicated in column 172, thenumber of calls in the queue as shown in column 174 and the longest waitfor a waiting call, for example as illustrated in column 176, as well asinformation regarding the name of the gate or functional representationof a call queue.

As mentioned above, the ACD home page 130, in addition to providing aninformation relating to the trunks connected to a particular ACD 22, 24,26, 28, 30 and 32, may also be used to provide information regardingequipment connected to the ACDs, such as EPNs. As mentioned above, oneor more customer care centers (CCC) may be connected to each of the ACDs22, 24, 26, 28, 30 and 32. Each of the CCCs may be formed from one ormore EPNs, which distribute the calls to the various agents at aparticular location. As such, the EPNs associated with an ACD may behyperlinked to an EPN web page, such as illustrated in FIG. 10 whichprovides additional information regarding the particular EPN, such asthe “port/card” assignment within the selected EPN cabinet. Suchinformation is relatively useful to a service technician who can look upthe information on the Intranet rather than looking through a number ofdetailed corporate records.

A load balance page is illustrated in FIG. 11. This home page may beprovided to display the traffic for an entire ACD. For example,referring to FIG. 2, the ACD 28 illustrates a CCC in Kalamazoo withthree EPNs; a CCC in Bethune with one EPN; a CCC in Southfield withseven EPNs; and a CCC in Saginaw with four EPNs. Referring back to FIG.11, the traffic load for each of the EPNs may be illustrated visually.For example, the load balance page may be provided with a plurality ofcolumns 180-188. The columns 180-186 may be used to indicate the portnetwork number, the EPN or host cabinet, name, the occupancy rate andthe highest occupancy rate ever of all of the EPNs as well as the hostcabinets. The occupancy information may be shown graphically by way of abar graph in column 188. For example, a left-hand portion 190 of the barchart may be used to represent the current occupancy for the previoushour while the right portion 192 may be used to represent the highestoccupancy ever.

Software

As mentioned above, the present invention continuously and automaticallypolls the ACDs over a dial up connection, captures data stored relativeto the ACDs and processes this data, for example, to generate theexemplary web pages illustrated in FIGS. 4 through 11. The system inaccordance with the present invention may be implemented with standardcommunications type software, such as Procomm Plus V4.7, available fromSymantec Corp., and adapted to provide continuous and automatic pollingand transmission of data stored in the ACDs. In one embodiment of theinvention, the system is adapted to transmit data, such as alarm data,gathered from the ACDs, to a paging platform to provide notification ofthe alarm status of the ACDs in addition to or in lieu of the web pagesillustrated in FIGS. 4 through 11. The communication software isillustrated in FIG. 12 while the paging software is illustrated in FIG.13. In particular, as will be discussed in more detail below, FIG. 12illustrates a modification to a standard communication software package,such as a Procomm Plus V4.7 package, for continuously and automaticallydialing up and logging in as well as retrieving data from the variousACDs in the network. The paging software illustrated in FIG. 13 may beused to send out a display page based upon the occurrence of majorand/or minor alarm conditions of the ACDs. The flow diagrams illustratedin FIG. 14 through 20 relate to processing of the data from the variousACDs in order to generate the various web pages illustrated in FIGS. 4through 11. Exemplary software written in C⁺ for automatically andcontinuously dialing up, logging and capturing data from the ACDs isprovided in Appendix 6. Exemplary software written in C⁺ fortransmitting alarm status to a pager platform is provided in Appendix 7.Although the C⁺ software illustrated in appendices 7 and 8 is writtenaround the Procomm communications software, the principles of thepresent invention are applicable to virtually any standard communicationsoftware package.

Appendices 1 through 5 relate to the C⁺ files for processing the dataretrieved from the various ACDs. In particular, Appendix 1, entitled“mic1.cfg” is a configuration file for the ACD 28, “Michigan-1”. Thisfile, “mic1.cfg”, identifies all of the equipment connected to the ACD28, “Michigan-1”. For example, with reference to Appendix 1, the fileidentifies the various inbound trunks from the long distance carriers 38and 40 (FIG. 1), DID trunks, the intermachine trunks (IMT); the outboundtrunks, the interactive voice response unit (IVR) trunks, the contactquality center (CQC) and the various EPNs connected to the ACD 28.

Appendix 2, entitled “mic1.eqp”, is an equipment file of all the variousequipment connected to the ACD 28; (FIG. 1) “Michigan-1”. As shown inAppendix 2, all of the equipment being monitored for the ACD 28 (FIG.1), “Michigan-1” is identified in Appendix 2.

Appendix 3 relates to a trunk file for the ACD 28 (FIG. 1),“Michigan-1”. For example, page 3 of Appendix 3 identifies Troy trunkgroup number 629. As shown on page 3 of Appendix 3, Troy trunk group 629is shown to consist of circuits 004 E 17; 005 E 17; 006 A 17; 007 A 17and 007 E 17, which corresponds to box 156 in FIG. 5A.

Appendix 4, entitled “mic1.gat”, relates to the agent's skill level forthe ACD 28 (FIG. 1), “Michigan-1”. This file is used to provide theagent status web page as illustrated in FIG. 9.

Appendix 5, entitled “mic1.pn” is a load balance file. This file is usedto provide the load balance web page as illustrated in FIG. 11. Forexample, as shown, this file is used to provide a load balance oroccupancy level of the various port cabinets as well as the EPNsattached to the ACD 28; namely Bethune, Kalamazoo, Saginaw andSouthfield.

Referring to FIG. 12 an exemplary flow diagrams for continuously,connecting to, logging into and capturing data from various ACDs isillustrated and generally identified with the reference numeral 200.Initially, an ACD is selected in step 202. The system then dials intoand logs onto the selected ACD in step 204. After the system logs ontothe selected ACD, the system waits for an answer back to determine ifthe connection was successful in step 206. If not, the system proceedsto step 209 and transmits and generates a carrier failure statusindication in step 209. After a successful connection, the system beginscapturing available data from the selected ACD in step 208 andsuccessfully reports the carrier status in step 210. After the carrierstatus has been reported, trunk group traffic information is receivedfrom the selected ACD in step 212. Subsequently, the alarm status istransmitted in step 214.

In order to provide some level of reliability of the data transmittedfrom the ACD, the system may periodically check the carrier connectionas illustrated in steps 216, 218, 220, 222 and 224. Anytime a carrierfailure is detected, the system proceeds to step 208 and generates acarrier failure indication.

Assuming that the system is connected, the status health of the selectedACD is transmitted in 226, after the system checks to see if it is stillconnected to the carrier in step 218. The system retrieves the trunkgroup load traffic data in step 228. After again checking the connectionof the carrier in step 220, the system retrieves the agent status datain step 230.

In step 232, the system retrieves the IVR port status after checking theconnection of the carrier in step 222. Subsequently, in step 234 thesystem retrieves all login data and terminates the data capture from theACD in step 236.

If any alarms have been detected, the system may be configured totransmit the alarm information to a paging platform, for example, asillustrated in FIG. 13 in step 238. Subsequently, in step 240 the systemselects the next ACD and loops back to step 202 to provide a continuousand automatic process for dialing up; logging into and capturing datafrom the next of the various ACDs in the network.

As indicated above, the system may be provided with the ability toprovide major and minor alarm status to a paging platform. The softwarefor transmitting the major and minor alarm information to a pagingplatform, for example, Procomm Plus, as illustrated in FIG. 13. Thissystem generally identified with the reference numeral 250 continuouslyloops waiting for major and minor alarms to be detected as mentionedabove in step 238. Once the alarm information is detected in step 252,the alarm data may be assembled in a batch file or other file suitablefor transmission to a paging platform. Once the alarm data is assembledin a suitable file, it is continuously transmitted to the pagingplatform in steps 256 and 258 until the paging platform indicates to thesystem 250 that the page was successfully received.

The software for processing the data captured from the ACDs isillustrated in FIGS. 14-20. FIGS. 14A-C illustrates the main loop.Referring to FIGS. 14A-C, the system begins by initializing its arraysand opening files in steps 260 and 262. As known in the art, in order todetermine the time corresponding to particular status informationprovided in an ACD, all ACDs are known to be provided with a real timeclock. Depending on the location of the ACD, different ACDs in a networkmay be in different time zones. As such, in steps 264 and 266, the realtime data from the ACDs is obtained and adjusted for the particular timezone for the ACD in processing. Subsequently, in step 268 the dataobtained from the ACD, as discussed above in FIG. 12, is read in step268. In steps 270-280, the system ascertains what type of data wascaptured. For example, in step 270 the system determines if systemhealth status data was captured. If the data with system health status,the system proceeds to step 280 and processes the system held data asillustrated in FIG. 15.

If the data is not system health status, the system next determines in272 whether the data is related to alarm information. If so, the systemproceeds to step 282 and processes the alarm information in accordancewith FIG. 16. If the data is not alarm information, the system nextdetermines whether the captured data was hunt group or agent statusinformation. If the captured data was hunt group information asdetermined in step 274, the system next proceeds to step 284 andprocesses the hunt groups information as set forth in FIG. 17. If thecaptured data was not hunt group information, the system next ascertainswhether the data is login status in step 276. If so, the system proceedsto process the login information in step 286 as illustrated in FIG. 18.If the data is not login status information, the system checks in step278 to determine whether the data is trunk information. If so, thesystem processes the trunk group information in step 288 as set forth inFIG. 19. If the captured data is not system health status data; alarminformation; hunt group information; login status or trunk groupinformation, the system next ascertains whether the data capture wasload balance information. If so, the system proceeds to step 290 andprocesses the load balance information as set forth in FIG. 20.

All of the data processing algorithms illustrated in FIGS. 15-20 returnto the main loop. Subsequently, after all of the various data isprocessed as set forth in FIGS. 15 and 20. The system computes thesummary information in steps 292 (FIG. 14B) and may load it into HTMLfiles for displaying by way of the web pages illustrated in FIGS. 4-11.In particular, system summary information may be used for example toprovide data for the ACD web page, for example, as illustrated in thedata boxes 132, 134 illustrated in FIG. 4. In step 294, the total numberof trunk groups is listed in column 140 in the data box 132. Next, instep 296, the total for the alarm status may be provided for the databox 134 (FIG. 4). Lastly, the summary information computed in step 292to report the number of agents in step 298 and the blockage in step 300from the information obtained in step 290 for display in the data box136 in FIG. 4. In step 302, the system identifies the various loginusers to the ACD in the data box 136 in FIG. 4. For example, as shown inFIG. 4, the user “barnh” is identified. Next, in step 304 the systemprocesses the system health. In particular, the system checks theoccupancy and idle time for reporting in the data box 136 in the ACDhome page illustrated in FIG. 4. In step 306, the system reports thecontact quality status (CQC) in the data box 132 on the ACD home page130 illustrated in FIG. 4. The CQC is treated like a trunk group and isreported as either “used” or “idle”. Next, in step 308, the systemreports the EPNs status. As mentioned above, the ACD web page includesan EPN hyperlink, linked to the various EPNs connected to the specificACD, for example as illustrated in FIG. 7A and 7B. As discussed above,this data may be used to provide occupancy (i.e. usage) information forthe various EPNs for example as illustrated in column 188 in FIG. 11.

As mentioned above, the system is adapted to provide an alarm log foreach ACD. An exemplary alarm log is illustrated in FIG. 8. Theinformation for the exemplary alarm log is generated by the system whichforms a historical file for all alarms captured in step 310 asillustrated in FIG. 20. In step 312, the data collected above is used tocreate a dynamic HTML file to provide virtually real time data by way ofa web page.

The software for processing the data captured from the ACD isillustrated in FIGS. 15-20. Referring to FIG. 15, the algorithm forprocessing the system health is illustrated. In step 314, 316 and 318,system checks data captured from the ACD relating to the occupancy ofthe ACD; idle time and whether the ACD is active. In addition, in step320 the system checks to determine if the ACD has been blocked out formaintenance activity. The system returns in step 322 to the main loop toprocess additional data retrieved from the selected ACD.

Alarm information is processed as illustrated in FIG. 16. In step 324,the equipment associated with each alarm is determined. This equipmentis then cross referenced in step 326 to process the data retrieved withthe specific equipment associated with the alarm (i.e., EPN Saginaw),for example as illustrated in FIG. 8. Next, in step 328 the systemidentifies the alarms in the data box 134 (FIG. 4) of the ACD web page130. The system returns in step 330.

A sub-system for processing hunt group information is illustrated inFIG. 17. The data processed by this sub system is used to create agentstatus web pages as illustrated in FIG. 9. Initially, in step 332 thesystem determines the status of each agent (i.e. skill level of agent;number of calls in the queue; longest wait for calls). In step 334, theagents are crossed reference to various gate groups, for example, thegates identified in FIG. 9. In step 326, the gates are grouped accordingto local assignments, for example as illustrated in FIG. 9. Theinformation may be used to create a dynamic HTML file for display on aweb page illustrated in FIG. 9. The system returns from step 340.

Login information may be processed as illustrated in FIG. 18. Thisinformation is used to identify the login users and the current systemstatus data box 136 (FIG. 4) on the ACD home page 130. Initially thissystem determines the number of active logins in step 342. For example,as shown in FIG. 4, the user “rbarnh” is illustrated. In step 344, theconnectivity is reported. As shown in the data box 136 in FIG. 4, theconnectivity method is shown as dial up versus direct connect (i.e.local log-in). In step 346, keyboarding messaging commands are reported.The most recent input messages by the user provide a historical audittrail of activity. The system returns in step 348.

The system for processing load balance information is illustrated inFIG. 19. This information is used to provide the load balanceinformation illustrated in column 192 of the traffic load web pageillustrated in FIG. 2. Initially, in step 350 historical load balancedata is read. This data is updated with the current load balanceinformation in step 352 and used to generate a HTML load balance file.In step 354, is used to generate the web pages illustrated in FIGS. 4and 11. In step 356, blockage thresholds are reported. The blockagethresholds relate to 0%-100% for growth potential of capacity exhaust).This data is used for the data box 136 of the ACD web page 130illustrated in FIG. 4. The system returns in step 358.

As mentioned above, the system may be used to generate an alarm log, forexample as illustrated in FIG. 8. Initially in step 362, the systemdetermines whether the alarm is new. If so, it determines whether thealarm is a major alarm in step 364. If the system is a major alarm, thesystem logs the alarm for transmission to a display pager in step 366.If the alarm is not a major alarm or if the alarm is not a new alarm,the system proceeds to step 368 for display on the web page illustratedin FIG. 8. The system may also include a step 370 for printing currentalarms. Subsequently, in step 372, the historical alarm log is updated.This information is used in step 374 to create a dynamic HTML file fordisplay, for example in FIG. 8. The system returns in step 376.

Exemplary HTML code for the web pages illustrated in FIGS. 4-11 isprovided in appendices 9-16 as indicated in the table below.

Figure HTML File Name Appendix  4 mic1.htm  9  5 mic1011.htm 10  6324230.htm 11  7 mic1epn.htm 12  8 mic1alm.htm 13  9 mic1agnt.htm 14 10mic1E14.htm 15 11 mic1load.htm 16

It should be appreciated that a wide range of changes and modificationsmay be made to the embodiment of the invention as described herein.Thus, it is intended that the foregoing detailed descriptions beregarded as illustrative rather than limiting and that the followingclaims, including all equivalents, are intended to define the scope ofthe invention.

1. A system for automatically monitoring the status of one or moreautomatic call distributors (ACD), the system comprising: means forautomatically establishing a communication link with said one or moreACDs; and means for automatically retrieving data from ACDs.
 2. Thesystem as recited in claim 1, wherein said establishing means includesmeans for automatically connecting to said ACD.
 3. The system as recitedin claim 2, wherein said establishing means includes means forautomatically logging into said ACD.
 4. The system as recited in claim2, further including means for processing the data retrieved from saidone or more ACDs defining processed data.
 5. The system as recited inclaim 4, further including means for generating one or more web pagescontaining data retrieved from said one or more ACDs.
 6. The system asrecited in claim 5, further including means for generating one or moreHTML files of processed data for presentation on a web page.
 7. Thesystem as recited in claim 6, further including means for generating oneor more HTML files of retrieved data for presentation on a web page. 8.The system as recited in claim 1, further including means fortransmitting portions of said retrieved data to a pager platform.
 9. Amethod for providing status information of one or more call distributors(ACD) comprising the steps of: (a) automatically and continuouslyretrieving data from said one or more ACDs; (b) displaying portions ofsaid retrieved data on one or more first web pages.
 10. The method asrecited in claim 9, wherein step (a) includes the steps of: (c)automatically connecting to said one or more ACDs; (d) automaticallylogging into said one or more ACDs; (e) retrieving data from said one ormore ACDs.
 11. A method for providing status information of one or morecall distributors (ACD) comprising the steps of: (a) automatically andcontinuously retrieving data from said one or more ACDs; (b) providingportions of said retrieved data to a paging platform.
 12. The method asrecited in claim 9, wherein step (a) includes the steps of: (c)automatically connecting to said one or more ACDs; (d) automaticallylogging into said one or more ACDs; (e) retrieving data from said one ormore ACDs.
 13. The method as recited in claim 9, further including thesteps of : (c) providing other data not retrieved from the ACDs; (d)displaying said other data on one or more second web pages.
 14. Themethod as recited in claim 12, wherein said second web pages arehyperlinked to said first web page.
 15. The method as recited in claim12, wherein said other data is static data.
 16. The method as recited inclaim 14, wherein said static data is trunk inventory record keepingsystem (TIRKS) data.